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Abstract: The Radiometer Electronics Box Assembly (REBA) is the control and data process- 
ing on board computer of the Low Frequency Instrument (LFI) of the Planck mission (ESA). The 
REBA was designed and built incorporating state of the art processors, communication interfaces 
and real time operating system software in order to meet the scientific performance of the LFI. We 
present a technical summary of the REBA, including a physical, functional, electrical, mechanical 
and thermal description. Aspects of the design and development, the assembly, the integration and 
the verification of the equipment are provided. A brief description of the LFI on board software is 
given including the Low-Level Software and the main functionalities and architecture of the Ap- 
plication Software. The compressor module, which has been developed as an independent product, 
later integrated in the application, is also described in this paper. Two identical engineering models 
EM and AVM, the engineering qualification model EQM, the flight model FM and flight spare have 
been manufactured and tested. Low-level and Application software have been developed. Verifica- 
tion activities demonstrated that the REBA hardware and software fulfil all the specifications and 
perform as required for flight operation. 

Keywords: Cosmic Microwave Background - space mission - Data Handling - Digital Signal 
Processing - Data Compression - Data Acquisition - Low-Level Software - SpaceWire - 
MIL-STD-1553B. 
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1. Introduction 

The Low Frequency Instrument (LFI, Bersanelli et al. 2009; Mandolesi et al. 2009) of the ESA 
satelUte Planck consists of an array of 1 1 corrugated horns feeding 22 polarisation sensitive pseudo- 
correlation radiometers based on HEMT transistors and MMIC technology. These are actively 
cooled down to 20 K by using a new concept sorption cooler. The radiometers cover three frequency 
bands centred at 30 GHz, 44 GHz, and 70 GHz. The LFI shares the focal plane of the 1.5m- 
aperture Planck telescope with the High Frequency Instrument (HFI), which is based on bolometric 
detectors cooled to 0.1 K (Lamarre et al. 2009). The combination of LFI and HFI is designed 
to provide full-sky maps of the microwave sky with an unprecedented combination of spectral 
coverage (30-850 GHz), sensitivity (AT /T ^ 10^^), angular resolution (~ 10 arcmin) and 
suppression of systematic effects. 

Each LFI radiometer correlates the signal from the sky with that of a reference blackbody 
source cooled to 4 K. At the end of the radiometric chain, the amplified signals are detected by 
square law diodes, DC amplified and transmitted to the Data Acquisition Electronics (DAE) for 
signal conditioning and digitization. 

The LFI array required a dedicated electronic system to perform on-board instrument control, 
command and data handling as well as the on-board scientific data processing with high reliability 
and robustness. These functions are carried out by the LFI Radiometer Electronics Box Assembly 
(REBA), which is described in detail in this paper. In particular, the REBA incorporates the com- 
pression algorithms needed to optimize the use of the satellite to ground available communication 
bandwidth. The expected output of LFI is 5.7 Mbps while the available effective bandwidth is the 
order of 53 kbps, implying a need for on board pre-processing of the raw data. The most relevant 
physical, functional, electrical, mechanical and thermal characteristics of the REBA, as well as the 
main software aspects, are described in detail in the following sections. For a broad description of 
the REBA in the context of LFI, see Section 4.4.2 in BersaneUi et al. (2009) on the DAE and its 
connection with REBA. 

2. Equipment overview 

The REBA is a warm electronics unit consisting of two separate identical units, one nominal and 
one redundant, which operate in cold redundancy under power supply control of the spacecraft. 
Each unit has an envelope of 270 x 233 x 108 mm^, is painted in mat black with an emissivity of 
0.9, and weights 4.32 Kg (see Figure [l|). The measured power consumption of the REBA is 22.7 W 
fully running and processing science data, while the measured total power consumption of LFI 
is 68.3 W. Each unit houses three stacked electronics modules and they are located on the lateral 
panels of the service module (SVM) of the spacecraft at about 300 K. 

Each REBA unit is connected to the instrument Data Adquisition Electronics (DAE) in the 
Radiometer Array Assembly (RAA) through the instrument harness and to the spacecraft Central 
Data Management Unit (CDMU) and Power Control Distribution Unit (PCDU) through the space- 
craft harness. Figure ^ shows the connections between the REBA nominal unit, the DAE and the 
spacecraft CDMU and PCDU. 
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Figure 1. REBA nominal and redundant flight models. 



The REBA incorporates very innovative advances in several areas, remarkably: i) new DSP 
processors like TSC21020E which were considered among the most advanced high-performance 
processors (18 MHz and wait state - ED AC protected) for scientific application in space missions; 
ii) very high velocity serial communications interfaces and, iii) new real time on-board operating 
system. 

The REBA provides the hardware to perform the following main functions: 

• On-board command and data handling. 

• On-board science data processing and compression. 

• Instrument control. 

• Communication with the spacecraft CDMU via a MIL-STD-1553B CDMS bus interface. 

• Communication with the LFI subsystem DAE via four IEEE- 135 5 full-duplex, bi-directional, 
serial, point-to-point data links. 

• Hardware initiaUsation and error management. 

• Memory Error Detection and Correction (ED AC). 

• Computer watchdog activity control. Internal on-board time management and synchronisa- 
tion with the CDMS. 

• DAE synchronisation. 

• On-board software storage and processing. 

• Internal housekeeping data acquisition. 

• S/C Power conditioning and internal power distribution. 

• Digital Input/Output interface with the DAE for control purposes. 

These functions are allocated to four functional units: the Data Processing Unit (DPU), the 
Signal processing Unit (SPU), the Data Acquisition Unit (DAU), and the Power supply Unit (PSU). 
The DPU and SPU are in charge of the telecommand, housekeeping and science telemetry process- 
ing and provide the functions to ensure that the hardware and software operate as planned. The 
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Figure 2. LFI functional block diagram (nominal). 



DAU performs the analogue to digital conversion of the housekeeping of the REBA itself, while the 
switching regulator of the PSU provides galvanic isolation converting the spacecraft (S/C) power 
bus voltage to a series of current limited, under/over voltage protected regulated voltages for the 
sections of the REBA. It performs the control of the DC/DC converter switching and distributes the 
electrical power to the SPU sub-units (DPU, SPU and DAU). Figure ^ shows a simplified functional 
block diagram of the REBA. 

The REBA is composed of three boards, two DSP boards and one board for the DAE interface 
function and the DC/DC Converter. The DPU Digital Signal Processor (DSP) board is in charge 
of the control of the different elements: its software controls the DAU board by means of the 
Internal Bus and it also controls the SPU DSP board by an external spacewire connection. The 
DC/DC converter supplies all the functions. Table [T] shows the DPU and SPU characteristics and 
performance. 

2.1 DSP module 

The Processor Module - see block diagram in Figure ^ is a Floating Point Digital Signal Processing 
CPU on a single board based on the DSP TSC21020F, radiation tolerant version of the ADSP21020 
from Analogue Devices. Its external and open Harvard architecture provides two complete bus 
systems for program (48 bits) and data (32 bits), allowing concurrent access and simultaneous 
fetching and data accesses or multiple data accesses on a single clock cycle. Expansion capabilities 
are provided via the backpanel system bus as well as a mezzanine auxiliary interface. The Processor 
Module implements into a single board: 6x32 Kbytes PROM, 256K x 64 bits EEPROM (EDAC 
protected), 512K x 56 bits program RAM (EDAC protected) and 5 12K x 40 bits data RAM (EDAC 
protected), 512K x 40 bits of Expansion RAM; three high-speed IEEE-1355 (SpaceWire) links. 
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Figure 3. REBA functional block diagram. 



asynchronous serial interface; Expanded interrupt capabilities; System Bus control; Programmable 
Watch-dog & system Timer and IEEE 1149.1 (JTAG) interface. 

General Features: TSC21020F IEEE 32/40 bits Floating Point Digital Signal Processor at up to 
18 MHz, wait states for RAM. Harvard architecture with independent program and data memory 
buses. IEEE 1 149. 1 1/F (JTAG) for testing and debugging. On-chip emulation. 6x32Kx48bits start- 
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Table 1. DPU and SPU characteristics and performances. 



Feature 



DPU 



SPU 



Program ROM Size 
Program RAM Size 
Data RAM Size 
Exp. Data RAM Size 
EEPROM Size 
Interface to MIL BUS 
OBT timer 



Included in Auxiliary Board 

PMPSC 

DMPSC 



32KWx48 

512 KW x 48 (0 wait state - EDAC protected) 
512 KW X 32 (0 wait state - EDAC protected) 

Not implemented 



256 KW X 48 



32KWx48 

512 KW x 48 (0 wait state - EDAC protected) 
512 KW X 32 (0 wait state - EDAC protected) 
5 1 2 KW X 32 (0 wait state - EDAC protected) 

Not implemented 
Not implemented 
PMPSC (Not used) 
DMPSC 



Watchdog timer 

SMCS Interface 
DSP Operation 
Interface to DAU 



- End of Acquisition Interrupt 

- Internal analog acquisitions 

- IHz Interrupt 

- Converter Sync status input 

- IHz signal control 

- DAE Power Status input 

- DAE reset SMCSl output 

- DAE reset SMCS2 output 

- Reset to SPU 



One IF with three LVDS channels 
18 MHz 

Not implemented 



Interface to DAE 



- DAE Data ready Interrupt 



Interface to SPU 



- Reset from DPU 



up PROM, 256Kx64bits EEPROM program bank (EDAC protected), 512Kx56 bits Program RAM 
(EDAC protected) and 512Kx40 bits Data RAM plus an optional 512Kx40 Expansion RAM bank 
(both banks EDAC protected). 6 Interrupt levels (4 of them through the System Bus) and IEEE 
Exception HandUng with Interrupt on Exception. Bi-directional IEEE- 1355 (Space Wire) based on 
SMCS332 and LVDS drivers capable of 100 Mbps data rates. Programmable Watch-Dog and 32 
bit system Timers. Power and Reset monitor. System Bus Interface (Master). Unit Monitoring and 
Control capabilities through System Bus. Standard development tools from Analog Devices. 

Key Design Features: Performance (at 18 MHz): 18 MIPS, 54 MFLOPS (peak) 36 MFLOPS 
(sustained). EDAC, UART, Timers, General purpose I/O registers and Glue logic integrated into the 
Processor Support Chip (PSC) ASIC designed and developed by CRISA. High degree of expansion, 
compatibility and configurability through the system bus interface and Auxiliary bus interfaces: 
The System Bus interface has been designed for connecting the DSP to maximise the expansion 
possibilities (I/O modules, etc.). The Auxiliary bus interface has been designed for connection of 
a mezzanine auxiliary board originally intended for high speed interfaces such as the 1553/OBDH 
bus interface, EEPROM/RAM expansion, etc. 

The purpose of the PSC Chip is: To enhance the on-chip memory management capabilities 
of the DSP, providing additional address decoding and wait state generator. Four 10 Areas are 
provided per decoding bank. To provide a flow through EDAC, configurable in width and enabling 
per I/O Area. To provide a simple 32 bit programmable Timer. To provide a Complex Timer 
configurable to provide a System Watchdog or an On-Board Time (OBT) support counter-timer. 
To provide a high speed UART. To provide buffer control in order to support the implementation 
of extension buses. The design of the PSC is compatible with the use in the PMB and DMB. It 
considers the bit aligning and bus wideness. 

2.2 AuxUiary board 

The 1553B Interface function is responsible for the communication between the DPU and the 
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Figure 4. DSP board diagram. 



CDMS. As part of the DPU board, this block is implemented on an independent board inserted in 
the Auxiliary Connector of the DPU board itself. The block diagram of this function is shown in 
Figure |5[ The external connection is of course to the 1553B Data bus. As required by the MIL- 
STD-1553 standard, the connection is made to both buses, and the implementation is by transformer 
coupling. The Remote Terminal Address, is discrepant to the standard being internally hardwired, 
and is different for the Nominal and Redudant Units. 

The architecture of the 1553B interface is built around the DDC BU61582. This hardened de- 
vice provides a completely integrated BC/RT/MT interface between the host processor and the bus, 
although its use in the REBA is reduced to Remote Terminal mode. It integrates dual transceiver, 
protocol, memory management and processor interface logic. It also includes internal 16Kwords 
of RAM which is not used in the design due to its very low speed characteristics. 

The interface for data with the DPU software is performed by means of a Dual-Port RAM. The 
software can also access the internal BU61582 internal registers, and an acknowledge generator is 
included to allow access even in case the component is processing commands. This circuit also 
ensures no conflict appears in the accesses to the Dual-Port RAM. 

The interface also includes circuitry to generate a general DPU reset on reception of a SA28R 
command over the bus. The block implements some logic to avoid feedback problems between this 
reset line, that is sent directly to the DPU, and the general reset line from the DPU that is activated 
immediately after. It introduces a delay allowing the transmission of the status response through 
the 1553 bus after the reception of the command. 

The interface with the DPU board through the Auxiliary connector also includes a buffering 
stage which is not part of the DSP board. This stage decouples the internal Aux board operation 



-7- 



EXTERN 
CONNECTOR 



IDI| resl:t 



' DUAL- 
(— RA 



rf:set_au 



DECO 
SA28 



INTERN 
CONNECTO 
TO DPU 



Figure 5. AUX Board Block Diagram. 



from the DSP activities. This board uses two secondary voltages supplies: 5V for the general logic 
as well as for the BU61582 and —15V, a devoted DC/DC converter output with its corresponding 
return line. The general logic and DC/DC converter return lines are connected in order to decouple 
the large peak currents related to the bus communications from the general supply lines. 

2.3 DAU function 

The DAU is included on the Power Supply Unit (PSU) board together with the DC/DC Converter. 
The DAU acquires the analogue housekeeping of the REBA performing analogue signal condition- 
ing, digital conversion, and transmission to the DPU via the back panel connector. 

Figure ^ shows the DAU functional blocks. The specific DAU functions are: Internal Bus 
Interface. Analogue to Digital Conversion. Acquisition Control. Clock Divider. Thermistors 
Conditioning. Secondary Currents Conditioning. Secondary Voltages Conditioning. Internal Test 
Voltages Conditioning. Status. 

The DAU is a slave function controlled by the DPU module. The DPU generates the Bus lines 
that handle the DAU by means of write and read bus cycles. The "Start of an acquisition cycle" 
signal is generated with a write command by the DPU. This command enables the Acquisition 
Control Block and starts a cycle of acquisition. The Status Block contains the following informa- 
tion: "Acquisition in progress" bit, when set, this indicates that an acquisition cycle was started and 
has not still finished; when cleared, this indicates that an acquisition cycle finished and a new cycle 
can be started. FIFO Flags: Three bits that indicate the FIFO status (empty, not empty, full, etc.). 
OBT clock status which indictes if the REBA OBT counter is using the external or internal clock. 

In the Analogue to Digital conversion block the analogue signals are routed to a 16 channel 
multiplexer stage of type HI-546. The selected signal is buffered by an OP-42 Operational Am- 
plifier and applied to the input of an Analogue to Digital Converter (ADC) type AD-574. The 9 
most significant bits output of the ADC are stored in a FIFO memory. The method of acquisition is 
cyclic. Once all the channels have been sampled and placed in the FIFO the Acquisition in Progress 
signal is deactivated so that the DPU can read out the data. 
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Figure 6. DAU block diagram. 



The RS-422 block of the DAU provides the interface to the DAE for the 1 Hz time synchro- 
nisation signal used by the DAE at power up and during the process of time synchronisation with 
the OBT. The signal is derived from the 2 Hz signal generated by the CPU. Its phase is controlled 
(by DPU software and by means of two signals) in order to ensure a rising edge when required, 
both at power up and during the synchronization procedure. Three temperature monitoring teleme- 
tries are provided by the DAU function: the DPU board temperature, the SPU board temperature 
and the PSU board temperature, using NTC type thermistor. Four secondary voltage monitoring 
telemetries are provided by the DAU function: the VCC voltage (logic supply), the +15V voltage 
(positive analogue supply) and the —15V voltage (negative analogue supply), and the — 15V_1553 
voltage. The currents of these secondary voltages, sensed at the active path of the secondary, are 
also provided. Each conditioning circuitry includes a filter with fc = 100 Hz. 

2.4 DC/DC Converter 

Figure ^ is a block diagram of the DC/DC Converter which uses the buck fed topology commonly 
used in space programs. The converter operation starts once the power bus is present at the input. 
There is no command to turn On or Off the converter. The "Buck stage" provides the voltage 
regulation at the output while the "push-pull stage" transforms the voltage to the output levels. The 
converter has both common mode and differential mode filters to reduce the emissions onto the 
main bus as shown in the block diagram. 

Once the PDUt power bus is available, the converter turns On in a smooth manner because 
the inrush current is limited by means of an external latching current limiter in the PDU to avoid 
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Figure 7. DC/DC converter block diagram. 



the peak current due to the charging of the differential filter Once the input filter is fully charged 
the converter starts operating. This is achieved by means of an under-voltage detector that does 
not allow the operation of the converter until the filter is completely charged. This is necessary 
to guarantee that the converter control electronics is supplied at the correct voltage and that the 
converter starts in a well known and safe mode. The DC/DC converter incorporates over-voltage 
protection. Over-current protection is implemented on the primary side by means of the buck stage 
in case of a short circuit or overload on the secondary side. 



2.5 Grounding concept 

The grounding of the REBA is via a single secondary return star point connected to equipment 
chassis in a single point. Primary return is isolated from chassis and from this secondary common 
return. Detailed grounding diagrams are shown in Figure ||. The different boards, including the 
mother board, include ground planes for the different secondary returns. 



2.6 Redundancy 

The whole of LFI was analysed during the early design phase for the effects of failures, and a 
redundancy approach was adopted to reduce the possibility of single point failures causing total 
loss of the instrument. As the REBA itself would inherently be a point of single point failure 
unless very complicated internal redundancy solutions were adopted that would themselves tend 
to compromise the overall reliability of the unit, a simple approach was adopted of replicating the 
unit for use in cold redundancy and thus also implementing cold redundant interfaces to both the 
service module of the spacecraft (which themselves were further redundant at the individual unit 
level) and the rest of the instrument. In addition the failure analysis of the REBA itself was used to 
make internal design choices and thus where reasonable mitigate single point failures. For example 
margins were applied to the processor memories to allow for the loss of single memory chips over 
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Figure 8. REBA Grounding diagram. 



the life of the unit in orbit. All component choices in the REBA were tightly controlled by the 
Planck Product Assurance Program under the product assurance rules of ES A and also burn-in and 
ESA derating requirements were applied to limit the possibility of the most likely cause of unit 
failure which would be in single components. 

3. Mechanical and thermal design description 

The REBA is an assembly of three modules plus base plate with motherboard and a top cover, 
distributed as is shown in Figure ^. In addition to these modules the REBA has one independent 
motherboard, called the auxiliary board. 

The principal objective of the thermal design was to avoid hot spots and high thermal gradients 
between the different parts of the unit. The PCB's are coated with varnish to ensure good radiative 
coupling between boards and this also contributes to the homogeneity of board temperatures. The 
PCB design includes thick copper planes and the preferred location on stiffener and/or wide copper 
tracks of components with high power dissipation. Externally, the box parts are painted in mat 
black with an emissivity of 0.9. 

The housing concept is an assembly of machined parts assembled by screws. The housing 
modules are mounted horizontally, stacked one on the top of the other. The REBA has two identical 
CPU boards, DPU (Data Processing Unit) and SPU (Signal Processing Unit), with some differences 
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Figure 9. REBA BOX outline. The names indicate the modules distribution. 



in terms of size of memory banks and external interfaces. The DPU Module has a higher stiffener 
than the SPU Module because it houses the auxiliary PCB. 

The I/O connectors and layout of the modules have been optimised in order to minimise the 
height of the box. MHD connectors serve as interfaces for electrical interconnections between 
modules through the motherboards. 

The Base Plate is a machined plate having a flat contact surface to the platform. This item has 
a pattern of mounting feet, total 6 (M4), located along the housing perimeter and machined from a 
single block providing a continuous flat bottom surface. The Top Cover is a 2 mm thick aluminium 
sheet. The modules that form also the sides of the boxes have lateral reinforcements to provide 
stiffness and thermal conductive coupling between the modules and the base plate. The boxes are 
assembled by means of screws, passing through the Top Cover and through the stiffeners to the 
base plate threaded inserts. The items of the housing are machined parts made of aluminium alloy, 
having through holes or threaded inserts along their edges to allow easy assembly, minimising the 
number of mechanical parts. Figures IC, 11, 12 and 13 show a view of the modules. 

The PCB is used for mounting components as well as printing wiring interconnections be- 
tween components. The components selected are surface mounted (SMT) whenever possible to 
minimise mass and volume. The components were selected for insertion mounting where high 
thermal dissipation was necessary through the stiffeners or the SMT versions were not available. 
The PCB is made of a resin polyimide and fibreglass multilayer laminate. The required surface 
to allocate the electronic components is optimised in order to have a minimum number of internal 
connections. 

The stiffener frames have several functions: To provide adequate stiffness to achieve natural 
frequencies on board above 140 Hz. This is achieved by machining them from a block of aluminium 
alloy with contours along the edges of the boards, and inner ribs dividing the PCB areas in to 
smaller unsupported sections. To provide PCB fixation by means of M2.5 screws in a sufficient 
number to guarantee structural redundancy and thermal conductive coupling. To serve as heat 
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Figure 10. PSU and DAU module. 



sinks for high dissipation components, such as power mosfets. To provide fixation for the I/O D*M 
and MDM connectors located on the front of the units. Internal interconnections between modules 
is performed by a motherboard using Medium High Density (MHD) connectors. The material used 
for the mechanical parts of the box is aluminium 6082-T6 and its surface treatment is chromate and 
Black paint. 

4. Design, development and AIV 

The following models were manufactured and tested at various levels. Two identical engineering 
models: EM and AVM, the engineering qualification model: EQM and the flight model: FM (both 
Nominal and Redundant). The REBA EM and AVM models are flight model representative of 
both the electronic circuitry interfacing the S/C and support the LFI flight software. Commercial 
electronic parts were used with the same technology and by the same manufacture for the circuits 
directly interfacing with the S/C subsystem as in the flight H/W. The REBA-EQM is representative 
of the FM with the following exception: the EQM electronic components are "extended range" type 
only; nevertheless, they have been procured from the same supplier as that of the FM components 
and have been produced with the same FM technology. The REBA-FM has full flight standard 
components and was verified by formal functional and environmental acceptance tests. In order 
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Figure 11. CPU SPU module. 



to save costs flight spares (FS) boards have been produced for replacement of failed or damaged 
equipment at the integration or launch sites if it had been necessary. 

The development of the REBA was split into four main phases: Preliminary Design Phase, 
Detailed Design Phase, Flight Design Qualification Phase and Flight Acceptance Phase. During 
the Preliminary and Detailed design Phases the equipment concept was confirmed, the interfaces 
were defined, and the requirements and the design were frozen. The Preliminary and Critical 
Design Reviews were also held. The EM and AVM model were produced during this stage. During 
the qualification Phase the flight baseline design configuration, the preparation of the plans and 
procedures for QM and FM testing, and the manufacturing, assembly, integration and qualification 
tests of the REBA QM were performed. This Phase was completed with the Qualification Review. 
The Flight Acceptance Phase was devoted to the manufacturing, assembly, integration and testing 
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Figure 12. CPU DPU module. 



of the REBA, nominal and redundant, flight equipment. The production of these models concluded 
with the corresponding Flight Delivery Review to allow integration of the REBA in the flight model 
ofLFI. 

Full self-procurement was established for the FEE parts for the EM and AVM. Components 
for the EQM and FMs were procured by a Central Parts Procurement Agency provided by ESA. 
Other specific components and materials such as ASICS, magnetic components, mechanical parts, 
etc., were procured by CRISA. All the assembly activities of electronic modules including equip- 
ment integration were performed by CRISA. A dedicated Product Assurance Plan was prepared 
to cover the quality assurance aspects related to the engineering, procurement, manufacturing and 
verification activities involved in the development of the flight models. 

The overall verification program consisted of two parts, the qualification program and the 
acceptance program. Qualification tests are performed on the EQM model, and acceptance tests on 
the FM model. The different models were submitted to test in order to verify their characteristics 
and behaviour in the following areas: physical, electrical, functional, mechanical, thermal vacuum 
and EMC. Table ^ provides a review of these tests performed on the qualification and flight models 
in a test matrix form. 
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Figure 13. Auxiliary board. 




Figure 14. REBA Vibration tests. 

5. REBA On-board software overview 

All the software of the LFI instrument is implemented in the Radiometric Electronic Box Assembly 
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Table 2. Verification matrix. The legend for the second and third columns is: (T) Tested; (Q) Qualification 
level and duration; (A) Acceptance level and duration; (R) Reduced (only in case of NC in QM tests). 



Test 


QM 


FM 


Inspection Tests 


T 


T 


Dimensions, mass, flatness & Roughness 


T 


T 


Centre of Gravity, Moment of Inertia 


T 


T 


Grounding, Electrical and Functional 


T 


T 


Shock Load Test 


Q 




Sine Vibration 


Q 


A 


Random Vibration 


Q 


A 


Thermal Vacuum 


Q 


A 


Conducted Emissions and Susceptibility 


T 


T 


Radiated Emissions and Susceptibility 


T 


R 


ESD 


T 





(REBA). The LFI On-board software is divided into the following software products: 

• REBA DPU Start-Up Software: Developed by CRISA. It performs the initialization of the 
DPU and allows the upload into memory of the DPU Application Software (DPU_ASW) 
which is stored in the DPU EEPROM. It also performs some hardware self tests to confirm 
the correct status of the unit. 

• REBA SPU Start-Up Software: Developed by CRISA. It performs the initiaUzation of the 
SPU and allows the upload into memory of the SPU AppUcation Software (SPU_ASW) 
which is stored in the DPU EEPROM. It also performs some hardware self tests to confirm 
the correct estate of the unit. 

• REBA Low Level Software Drivers: Developed by CRISA. These provide a set of functions 
which allows the application software to access the different parts of the hardware. 

• REBA Application Software: Developed by LAC. It performs the complete operation of the 
LFI instrument. It is spUt in two appUcations running in the two CPU's inside the REBA, 
namely, DPU appUcation Software (DPU_ASW) and SPU appUcation Software (SPU_ASW). 

• Compressor and Decompressor Software: Developed by LAC, the compressor is imple- 
mented as a function of the SPU_ASW. Its development was performed as a separate product 
and then, integrated in to the SPU_ASW. 

5.1 REBA Low-level Software 

The REBA low level software consists of the Start-up Software (SUSW) and the Low-Level soft- 
ware drivers (LLSW_DRV). The DPU and SPU SUSW perform the necessary functions to boot the 
unit at power up, perform a health self-test and start the ASW giving it the control. Both programs 
are stored and executed from the DPU and SPU PROMs. 

The DPU SUSW is in charge of performing the following tasks: Power up initialization. Re- 
set source discrimination. Hardware self-tests. Hardware initialization/configuration. Perform 
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command reception/execution loop, receiving commands and sending responses through the 1553 
interface. Transfer control to ASW, upon reception of appropriate command. The SPU SUSW is 
in charge of performing the following tasks: Power up initialization. Reset source discrimination. 
Hardware self-tests. Hardware initialization/configuration. Perform command reception/execution 
loop, receiving commands and sending responses through the 1355 interface. Transfer control to 
ASW, upon reception of appropriate command. 

The Low-Level software drivers (LLSW_DRV) package is a set of primitives (source/object 
code) that provide easier access to functionalities of the different DPU/SPU HW devices which 
are compiled/hnked with the ASW. The LLSW_DRV includes the following drivers: MILSTD 
1553 (ACE device). Watchdog. OBT. Data Acquisition Unit. SMCS 1355. Interrupts. EDAC. 
EEPROM. General definitions. Error codes. Hardware map. DSP 21020 driver. PSC driver. Soft- 
ware reset function. Memory management. Both, LLSW_DRV and SUSW are coded in C and 
Assembler languages and are implemented using the Analogue Devices Software Development 
Environment ADSP-21020 Family Development Tools, release 3.3 for PC. The Architectural de- 
sign was performed using HOOD/UML tools. Software requirements verification was carried out 
by test, analysis or assessment (review of the design). Unit testing was performed using the ATTOL 
unit tests tool and for the software integration the Analogue Devices DSP 21020 Emulator. SUSW 
and LLS W_DRV software packages have been developed according to Planck LFI REBA/Herschel 
PACS SPU SW Quahty Assurance Plan and comply with the CRISA SW Configuration Manage- 
ment Plan. 



5.2 REBA Application Software 
5.2.1 Functionalities 



The Data Flow Diagram in Figure 15 shows the main functions performed by the REBA_ASW. 
The CDMS communication component is in charge of packing and transferring all data produced 
in the instrument (Telemetry): science data reduced and compressed (sc_drc), housekeeping pack- 
ets of the whole instrument (hk_pcks), events and execution reports (exec_reports), according to 
CDMS protocols (high and lower levels). This component also receives and decodes every TC 
received from the CDMS according also to CDMS protocols (high and lower levels) to produce 
valid instrument commands ready to be executed, immediately (valid imm TC) or waiting in an 
execution queue for eventual previous TCs execution (valid TC). 

The main function of the REBA_ASW is to receive from the Data Acquisition Electronics 
(DAE) the raw science data (Sc_raw) collected by the LFI radiometers and reduce and compress 
these data (Sc_drc) to within the allocated bandwidth allowed to the instrument. The baseline 
for the science data processing is to average, perform differences and compress the data of all 
the detectors, nevertheless, the type of processing as well as the selection of the detectors to be 
processed is modifiable by TC (scproc_cmd). Some parameters needed for the science processing 
can also be modified by TC (scproc_pars). 

The REBA_ASW also collects housekeeping from the whole instrument. These data are col- 
lected from the Data Acquisition Unit (DAU) inside the REBA (dau_hk), which supplies informa- 
tion on the REBA itself, and from the DAE (dae_hk) which supplies information about the rest of 
LFI instrument. Other housekeeping is produced by the REBA_ASW itself, as is the case for the 
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Figure 15. REBA_ASW main functionalities. 



processing of the science data (drc_hk) as well as other parameters (not included in the diagram 
for simplicity). This function is performed by the HK acquisition component. The operator may 
also require by TC (hk_cmd) special HK information for diagnostics and debugging purposes. The 
housekeeping collected are sent to the CDMS as specific types of TM packets (hk_pcks) and some 
of these are also checked by the REBA_ASW to control the health of the instrument (monit_hk). 

This automatic checking is performed by the "Monitoring & Autonomy functions component", 
which takes care of the CPU load in the SPU, temperature of the focal plane; science TM rate 
and instrument internal communications links. When the chosen values exceed certain nominal 
values (nom_val), an alarm is sent to the CDMS (events) and an autonomy function is activated to 
maintain the system in safe conditions. It is also possible to command (monit_cmd) this component 
for testing and debugging purposes. 

Finally, the other main component of the REBA_ASW is the management of the TCs received 
from the CDMS, Execution of TCs component. It controls the coiTcct execution of the incoming 
TCs (valid_TC and valid_imm_TC) which operate the instrument. It only allows the execution 
of TCs under certain conditions of the system. It sends the TC to the appropriate subsystem or 
component when needed, checks the completion execution and notifies the CDMS about the re- 
sults (exec_reports). The transmission of TM packets to the CDMS may also be modified by TC 
(enbl_dsbl_transfer) for testing and debugging purposes allowing the enabUng and disabling of the 
transmission of different telemetry packets. 

Detailed functional requirements as well as all software requirements are defined in [|],|||], and 
1^] complete the specification of REBA Application software which has been developed following 
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Table 3. Metrics. Legends in columns mean: (a) C Source modules. Number of C source files as well as 
include files; (b) C functions. Number of functions implemented in C language; (c) Assembler functions. 
Number of functions implemented in assembler; (d) Code lines: Number of lines, not blank and not com- 
mented; (e) Comment lines. Number of comment Unes explaining the source code; (f) Nesting Max: An 
average over the total functions of the maximum statement nesting level in the function (0 for sequential 
code); and (g) McCabe: An average over the total functions of the McCabe's cyclomatic complexity, i.e. an 
average per function of the number of linearly independent control paths. 





Source Modules 


C functions 


Assembler functions 


Code lines 


Comment lines 


Nesting Max 


McCabe 


DPU_ASW 


41 


264 


4 


10100 


14091 


2.53 


5.44 


SPU_ASW 


36 


139 


3 


4679 


7341 


2.09 


4.13 


Compressor 


2 


10 





224 




1.4 


3.7 


Decompressor 


2 


9 





242 




2.22 


5.22 



the ESA software engineering standards for small projects BSSC(96) 2. 

5.2.2 Architecture 

The REBA_ASW is composed of two applications programs running on the two CPU's of REBA, 
DPU application software (DPU_ASW) and SPU applications software (SPU_ASW), respectively. 

Both applications were developed in C language and are executed under the real time oper- 
ating system Virtuoso, from Eonic Systems. Some specific functions, critical in time, have been 
implemented in assembler. 

To cope with the functionalities described in the previous paragraph, REBA_ASW has been 
built by the use of different Virtuoso objects. It is composed of a set of Virtuoso tasks which 
interface among them by the use of some Virtuoso Fifos, memory maps as well as global variables. 
Problems of racing and concurrency have been solved by an appropriate definition of a priority 
scheme of tasks as well as the use of Virtuoso semaphores and resources. Virtuoso timers have 
also been used to implement some cyclic activities. In Appendix ^, we list and describe the most 
important tasks of the REBA_ASW. 

5.2.3 Verification and Validation 

A total of 91 test procedures were defined and executed to ensure that the REBA_ASW fulfils its 
software requirements. The validation was performed against the Software Specification Docu- 
ment, [^. Validation is completely defined in [^]. 

The acceptance tests consist of a set of validation procedures in a specific order. These accep- 
tance tests have been executed for each REBA hardware model. 

Unit tests have been executed at function level to check that each function executes according 
to its detailed design. Different tests cases for each function have been executed to guarantee a 
100% statement coverage. More details about unit tests can be found in 

5.2.4 Metrics 

Table ^ provides metrics which indicate the maturity of the REBA_ASW. 
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6. The SPU Compressor Module 



6.1 Compressor requirements 

The LFI scientific mission requires compressing the scientific data in order to make maximum 
use of the satelhte to ground communication bandwidth. lAC developed the compressor function 
which has been integrated in the SPU appUcation software. A decompression function was also 
developed and delivered to the Data Processing Center (DPC) in order to be integrated in to the 
ground application software. 

The SPU compressor component is particularly complex and, therefore, a complete set of 
formal software documentation has been generated and delivered specifically for both compressor 
and decompressor functions, consisting of a software specification document ([[l^]), which includes 
SW requirements and architecture design, a software verification and validation plan document 
(1 12]) and its corresponding validation plan report ([pT|]), and a unit test plan and unit test report 



documents. 

The compressor input signal is expected to be dominated by white gaussian noise, with in- 
formation content or entropy for 30 GHz channels of // 5.16 bits, which allows for a maximum 
compression ratio of Cr^p 3. 10, and the specified minimum compression ratio for such a signal is 
about Cri-eq ~ 2.5. In addition, the compressor is required to be lossless and adaptive, which means 
recovering the exact input signal after decompression, and optimizing compression performance in 
spite of variations in the input signal statistics, respectively. All these requirements, together with 
the common requirements of on board compressors of working in real time and packetizing output 
data in independently decompressable packets, has led us to a careful selection of the compression 
algorithm, and a great deal of work to adapt it to the LFI compressor requirements. 

Arithmetic coding is the method of choice for lossless adaptive entropy compression on mul- 
tisymbol alphabets because of its high speed, low storage requirements and effectiveness of com- 
pression. The final SPU compressor is an adaptation of the implementation of the arithmetic coder 
by A. Moffat, a widely used non commercial version which has become a standard ([pl]). 



6.2 Compressor general architecture 

Adaptation of Moffats algorithm to LFI requirements has been viable thanks to its modular archi- 
tecture. Figure |T6| shows the modular architecture of the SPU compression function (0]). This 
function is called by the SPU application SW with the aim of generating a single compressed data 
set for a single science TM packet. Each time the function is called, all the relevant compression 
variables are set to the same initial values. 

The coding module is the core of the compression function, and those options that maxi- 
mize the compression factor without penalizing execution speed have been chosen. For example, 
multiplications and divisions are allowed, because they are supported by the DSP as primitive oper- 
ations, and permit a better compression efficiency; and frugal bits mode is selected, so that coding 
termination is made with as few nonambiguating bits as possible. 

The modelling module informs the rest of the modules about the nature and characteristics 
of the signal. The model is a 16 bit integer zero order adaptive model, which means that 16 bits 
uncorrelated input samples are assumed, with an unknown initial statistic. 
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Figure 16. Modeling, statistics, coding, input and output modules. 

The statistics module manages the Fenwick Tree structure that stores the symbols cumulative 
frequencies. Accessing the structure takes 0{log2{n)) instructions per symbol, where n is the size 
of the alphabet, and so the cost is small even when n is very large (which is our case with n = 2^^ 
symbols). Initially, the symbols occurrence frequencies are set to zero. In order to code a symbol 
with a zero occurrence frequency, an escape symbol is coded followed by the raw symbol. This 
allows a fast initialization that would otherwise prevent real time operation. This also allows the 
statistics table to truly represent the signal statistics right from the beginning of the compression 
operation with as little increment in a symbol occurrence frequency as unity per new symbol, so 
that no time consuming functions are needed to readjust the statistics table because of overflow. 

Input and output modules read the input data and write the output data according to the in- 
terface requirements with the SPU application software. The output modules take care that the 
maximum allowed size of a compressed data set per TM packet is not exceeded. 

6.3 Performance validation and results 



A formal SW validation has been conducted (see [11] and [12]) against the compressor SW re- 
quirements specified in [|T^]. Concerning performance on compression ratio and execution time 
the developed compressor is compliant. For a Gaussian white noise signal with an optimal com- 
pression ratio of around Crop ~ 3, the minimum achieved ratio is Cr = 2.5, and the maximum 
execution time per generated packet is 46 ms. 

Also the compressor ratio has been characterised against noise with different probability den- 



sity functions (see [|10|]). Figure |17| shows the percentage of achieved compression ratio versus the 
optimal, for Gaussian, uniform and 1 // types of noises. We can see that the compressor behaves 
slightly better for uniform noise than for the other two types. This is because a uniform proba- 
bility distribution is more robust against roundoff error due to integer arithmetic divisions when 
calculating the symbol's probabilities. However, for a Gaussian noise, which is the most represen- 
tative of the actual expected scientific input signal, the achieved compression ratio is specification 
compliant. 
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Figure 17. Achieved compression ratio per packet (in %) vs. the optimal compression ratio per packet for 
Gaussian, uniform and 1// noise distributions. 



7. Conclusions 



The Radiometer Electronics Box Assembly (REBA) is the control and data processing on board 
computer of the Low Frequency Instrument (LFI) of the Planck mission (ESA), consisting in two 
separate identical units, which operate in cold redundancy under power supply control of the Planck 
spacecraft. Each REBA unit is connected to the instrument DAE and to the spacecraft CDMU and 
PCDU. REBA performs, among other functions, on-board command and data handling, science 
data processing and compression, software storage and processing, and control of the LFI. It has 
four functional units: DPU, SPU, DAU and PSU. It is composed of two DSP boards and one board 
for the DAE interface function and the DC/DC Converter. 

We have manufactured and tested at various levels engineering models (EM and AVM), the 
engineering qualification model EQM and the flight model FM (both nominal and redundant). 
Specific software was developed to carry out the start-up of the DPU and SPU, to perform the com- 
plete operation of the LFI instrument, and to carry out on-board data compression in order to make 
maximum use of the satellite to ground communication bandwidth. The compressor function was 
integrated in the SPU application software. The performance on compression ratio and execution 
time was found in agreement with the specifications. 

After launch of the Planck satellite on May 14th 2009, the REBA hardware and software 
performs well and fulfil successfully all the specifications for flight operations. 
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A. Abbreviations and acronyms 



ASIC 


Application Specific Integrated Component 


ASW 


Application Software 


AVM 


Avionic Model 


CDMS 


Central Data Management System 


CDMU 


Central Data Management Unit 


DAE 


Data acquisition Electronics 


DAU 


Data Acquisition Unit 


DMB 


Data Memory bus 


DMPSC 


Data Memory Processor Support Chip 


DPU 


Data Processing Unit 


DSP 


Digital Signal Processor 


EDAC 


Error Detection and Correction 


EQM 


Engineering Qualification Model 


ESA 


European Space Agency 


ESD 


Electro Static Discharge 


FIFO 


First-In First-Out 


FM 


Flight Model 


FS 


FUght Spare 


Gxxxx 


230 xxxx 


HW 


Hardware 


10 


Input/Output 


Kxxxx 


210 xxxx 


LFl 


Low Frequency Instrument 


LLSW 


Low Level Software 


LLSW_DRV 


Low Level Software Drivers 


Mxxxx 


220 xxxx 


PCDU 


Power Control Distribution Unit 


PCB 


Printed Circuit Board 


PMB 


Program Memory Bus 


PMPSC 


Program Memory Processor Support Chip 


PROM 


Programmable Read-Only Memory 


PSC 


Processor Support Chip 


PSU 


Power Supply Unit 


RAA 


Radiometer Array Assembly 


RAM 


Random Access Memory 


REBA 


Radiometer Electronics Box Assembly 


ROM 


Read-Only Memory 


S/C 


Spacecraft 


SMCS 


Scalable Multichannel Communication Subsystem 


SPU 


Signal Processing Unit 


susw 


Start Up Software 


SVM 


Service Module 


SW 


Software 


TC 


Telecommand 


TM 


Telemetry ^5 



B. DPU_ASW and SPW_ASW architectures 



Table 4. DPU_ASW Architecture: Tasks 



Task 


Description 


Priority 


tDpuInit 


This task is the execution entry point of the complete ap- 
pUcation. It initiaUzes all variables and Virtuoso objects 
(semaphores, timers, etc.) and starts the rest of tasks. Af- 
ter this initialization it aborts its own execution. 


8 


tCdmsDrv 


Implements the transfer layer protocol to communicate 
with the CDMS. This communication is based on an inter- 
rupt handler which is executed at reception of two types of 
interruptions produced by the 1553 interface, that is, one 
interruption at subframe level (1/64 seconds) and the sec- 
ond one at frame level every second. The interruption at 
frame level is also used to perform the synchronization of 
the REBA with the spacecraft time. It manages TCs re- 
ceived by vahdating the TC received and executing those 
of immediate type and storing in a FIFO and a memory 
map those which are queue TCs. These later are processed 
by tTcExecution task. This task also interfaces with TM 
rate monitoring task by storing in a global variable the to- 
tal of dehvered science TM packets. 


10 


tDpuDmpscDrv 


This task manages events and errors produced by the Pro- 
cessor Support Chip (PSC) of Data Memory of SPU. 
These events are detected by interruption. This includes 
the management of EDAC single and double failures in 
data memory, watchdog and hardware errors on the 1553 
interface. Single EDAC failures are also corrected by this 
task. 


16 


tDpuPmpscDrv 


This task manages events and errors produced by the Pro- 
cessor Support Chip (PSC) of Program Memory of DPU. 
These events are detected by interruption. This includes 
the management of EDAC single and double failures in 
program memory as well as the 1 Hz signal which is used 
to perform the synchronization of DAE. 


17 
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[h!] tDpuSmcsDrv 


This task implements the low level communications of the 
3 links of the 1355 interface. Link 1 is used for communi- 
cations between DPU and SPU and link2 and link3 is used 
to communicate DPU with DAE. While Unk 3 is used for 
transmission of data between DPU and DAE, link 2 im- 
plements the called "control by link", that is, as DAE has 
no software, the operation of the DAE SMCS chip must 
be commanded through a link, so, DPU commands DAE 
oiviv^o lo penorm me appropnaie iransmission ana recep- 
tions through this link. Depending on the information of 
the interruption, this task signals appropriate semaphores 
or set values in a FIFO; these Virtuoso objects are then 
used to communicate to other higher level tasks of com- 
munications. 


18 


tDpuRcvFromSpu 


This task processes the different packets received from 
the SPU, the discrimination of the reception is based on 
a FIFO. The reception is performed in a double buffer in 
such way that while a packet is being processed another 
one can be received. According to the type of packet it per- 
forms different activities, such as, saving SPU HK infor- 
mation for further packing of REBA HK packet; obtain- 
ing science diagnostics data for further science diagnostic 
statistics generation; storing in a FIFO the SPU CPU load 
for monitoring, etc. 


25 


IKc DariK/\cq 


DaseQ on a i secona iimer, ii couecis nominal as wen 
as diagnostic acquisition data for REBA HK packet. The 
complete diagnostic data are collected for each sample pe- 
riod and, depending on the transmission enabled of TM 
packets, this is sent or reduced to just send the nominal 

ValUCa, a slllallCl UaCJvCL. 




tDaeHkAcq 


Based on a 1 second timer, it collects and packs the 2 types 
of DAE HK data, that is, fast HK (every 1 second) and 
slow HK (every 64 seconds). It also selects and stores in a 
FIFO the Focal plane temperature (Fpt) values for further 

Tnotiitofino' iiti^il\/cic 
iinjiiinji 111^ diidi y oio . 


31 


tFptMonit 


Implements the monitoring of the Focal Plane by check- 
ing the values stored in a FIFO. After comparison with a 
threshold value it also sends an event report and executes 
an autonomous function which commands DAE to switch 
off the 4 DC/DC converters of the Front End Unit. 


35 
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[h!] tCpuMonit 


Implements the monitoring of the SPU CPU load by 
checking the values stored in a FIFO. When limit is ex- 
ceeded it sends an event report. 


36 


1 1 nirivioiiii 


rsasea on a umer, wnose penoa is connguraoie oy uie 
user, the total of science TM delivered is checked. When 

the TM rate exceeds the expected values an autonomous 
function to disable the processing in some detectors is ex- 

CCULCU. IIIC Ui&aUlillg i& Ua&CU Oil a LaUlC WliLCll Call UC 

configured by the user. 


JO 


iDpuEventMngr 


All errors produced in the DPU system are managed by 
this task. It processes all errors from a FIFO which is 
filled by all tasks when errors are produced. This task also 
distinguishes when the error must be sent as event reports. 


40 


tTcExecution 


Obtain from a FIFO the queued TCs pending of execu- 
tion. These TCs are already vaUdated. The FIFO con- 
lains uie sioruig iniormauon reierrea lo a memory map 
where the complete TCs are stored. Once the TC is exe- 
cuted, it sends the corresponding execution report, success 

or fail 1 irp ^ \/nr*hroTii 7ati on of hoth R PR A anH AT-*" i c 

performed by the coordination of this task with tCdmsDrv 
and tDpuPmpscDrv tasks. See later. 


45 


iDpuMemoryScrub 


Based on a 24 hours timer, it reads all memories of DPU. 

This allows to correct eventual single EDAC errors, de- 
creasing, on this way, the risk of double EDAC failures. 


60 



An important aspect to mention of the tTcExecution task is the synchronization of REBA and 
DAE to the spacecraft time. REBA synchronization is carried out by the use of global variable and 
a semaphore. TcExecution task set a flag to indicate the synchronization process to tCdmsDrv task. 
When this flag is asserted tCdmsDrv uses the one second interruption of 1553 interface to set the 
REBA OBT according to the time received, a semaphore indicates to the tTcExecution task that the 
synchronization has finished. A similar process to verify the REBA time is followed. DAE syn- 
chronization process is similar; in this case, tDpuPmpscDrv task guarantees that the synchronized 
time is passed to DAE in advance to a 1 Hz interruption which is used by DAE to latch its time. 
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Table 5. SPU_ASW Architecture: Tasks 



Task 


Description 


Priority 


tSpuInit 


This task is the execution entry point of the complete ap- 
plication. It initializes all variables and Virtuoso objects 
(semaphores, timers, etc.) and starts the rest of tasks. Af- 
ter this initialization it aborts its own execution. 


8 


tSpuDmpscDrv 


This task manages events and errors produced by the Pro- 
cessor Support Chip (PSC) of Data Memory of SPU. 
These events are detected by interruption. This includes 
the management of EDAC single and double failures in 
data memory, watchdog and the Data Ready signal coming 
from DAE which indicates that a new set of science data 
has been stored in DAE DPRAM and it is ready for being 
transferred to SPU. This is done by asserting a semaphore. 


16 


tSpuPmpscDrv 


This task manages events and errors produced by the Pro- 
cessor Support Chip (PSC) of Program Memory of SPU. 
These events are detected by interruption. This includes 
the management of EDAC single and double failures in 

program memory. 


17 


tSpuSmcsDrv 


This task implements the low level communications of the 
3 links of the 1355 interface. Link 1 is used for com- 
munications between SPU and DPU and link2 and link3 
is used to communicate SPU with DAE. While link 3 is 
used for transmission of science data from DAE to SPU, 
link 2 implements the called "control by link", that is, as 
DAE has no software, the operation of the DAE SMCS 
chip must be commanded through a link, so, SPU com- 
mands DAE SMCS to perform the appropriate transmis- 
sion through this link. Commands received from DPU are 
stored in a FIFO which is processed later by the tCmdExec 
task. The communications with DAE are managed by two 
semaphores. 


18 
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[h!] flnitialScProc 


This task starts its activity based on a semaphore which 
is signaled when Data Ready signal, asserted by DAE, is 
detected. Performs initial processing of science data in- 
cluding data acquisition from the DAE, data validation, 
and depending on the processing type(s): data summing, 
differencing, re-quantisation and offset. Data are stored in 
circular buffers implemented by a Virtuoso memory map. 
It organize the science data separating by detectors and, 
depending on ine processing type, il stores raw uaia in cir- 
cular buffers or performs the sum of the data before store 
it. Communicates that a science packet is ready to be com- 
pressed and/or packaged through a FIFO. 


25 


t<;r>iii-rvr^p>n 

LopU-tlKOcn 


DdScd Oil a 1 second Lllliei, IL collects or U nJv data alld 

transmit this data as a packet to DPU. 


jyj 


tSpuEventMngr 


All errors produced in the SPU system are managed by 
this task. It processes all errors from a FIFO which is 

llllCU uy all LdSKS WllCll CITUriS dTC prULlUL/Ctl. llllIS uilSK d-llSU 

distinguishes when the error must be sent as event reports. 


40 




iidiisiiiiis a ocieiice or u pdCKei lo iiie ur u. iiiese pacK- 
ets have been previously stored in SPU DPRAM. A FIFO 
with memory addresses of Sc packets is the interface with 
tFinalScProc task. 




tCmdExec 


It listens from linkl commands received from DPU and 

executes the corresponding command. 


45 


tFinalScProc 


Performs final processing of science data, including data 
compression (^depending on me processing lype^. ii od- 
tains packets ready to be compressed and/or packaged. It 
interfaces with tInitialScProc through a FIFO. TM packet 

Is ^CllClaLCU. Ill a QCCllCaLCU. U.UUU1C UUllCl 111 UlC Oi LJ 

DPRAM, this double buffer allows to transmit a packet 
while new packet is being produced. 


50 




RacpH on timpr of IS minntPQ it i^nahlpc paph ?i Hp- 

tector in sum data processing type in one of 2 provided 

simultaneous processing groups. 


58 


tSpuMemoryScrub 


Based on a 24 hours timer, it reads all memories of DPU. 
This allows to correct eventual single EDAC errors, de- 
creasing, on this way, the risk of double EDAC failures. 


60 



-30- 



